MIME-Version: 1.0
Server: CERN/3.0
Date: Monday, 06-Jan-97 22:47:08 GMT
Content-Type: text/html
Content-Length: 4052
Last-Modified: Wednesday, 06-Nov-96 21:03:45 GMT

<html>
<head>
<title>Quotes screaming for Formal Methods</title>
<body>
<h1>Quotes screaming for Formal Methods</h1>
This is a list of quotes that may convince you that some kind of
formalism is needed in the development of critical software. 
<hr>
<h3>From the Arianne 5 Crash report, July 1996:</h3>
<q>"... the view had been taken that software should be considered correct
until it is shown to be at fault." </q><br>

<!WA0><a href="http://www.cs.utexas.edu/users/kornerup/ariane5rep.html">Read the full report</a>
<br>
<h3>The *Daily Telegraph* 1 Oct 1996: "When Failure is Out of the Question"
by Paul Forster</h3>
<q>
National Air Traffic Services Ltd., part of the Civil Aviation Authority, is
close to completing a new (pounds) 300 million centre at Swanick . . .  "It's
all digital and probably the most advanced ATC setup anywhere," says Dr John
Barrett, the Swanick project director, almost nonchalantly. "It's so complex
I have difficulty in explaining it even to my board," he says.  Throughout,
safety is paramount. The whole system is made up of networked workstations
rather than a central mainframe, so there is no single point of failure. . .
The system totals roughly two million lines of software, but like most
software it is behind schedule and is still being debugged .  . . Operations
are not now due to begin until the winter of 1997 . . .  "With ATC it's
obvious that we simply have to remove all the faults in the code, and we are
now working 24 hour a day, seven days a week," says Barrett. "Our
over-arching requirement is that the system has to be completely safe."
</q>
<br>
Posted to Risk Digest 18.50, by Brian Randell, Dept. of Computing Science, University of Newcastle

<h3>September 16 1996 issue of *Aviation Week & Space Technology*
(pp. 24-25).</h3>
from David A. Fulghum's "Hard Lessons in Iraq Lead to New Attack
Plan" in the September 16 1996 issue of *Aviation Week & Space Technology*
(pp. 24-25).
<br>
<q>
The article states: "Bomb damage assessment of the initial cruise missile
strike indicates that three of the 10 targets attacked by 13 Air Force
CALCMs (Conventional Air-Launched Cruise Missiles) emerged with "no
detectable damage," according to a U.S. intelligence report.  The Boeing
built CALCMs, converted from Cold War-era nuclear weapons at a cost of
$165,000 each, were launched from two B-52H bombers over the Persian Gulf."

Apparently: "Part of the problem with the CALCMs were that they were fired
at targets they were not designed to destroy, a product of hasty planning,
according to a senior Pentagon official. Air Force success rates were
further deflated because of missile computer programming quirks."

Further on: "Another CALCM target escaped damage because of a software
targetting quirk left over from its nuclear role. If two CALCMs are aimed at
the same target at the same time, one of the missiles will re-aim itself at
the next highest priority target. In the initial raid, one CALCM missed the
target while the other went on to the next site."
</q>
<br>
Posted to RISK Digest 18.56 by Kofi Crentsil (crentsil.k@atomcon.gc.ca)

<h3>*Electronic Engineering Times*, 28 Oct 1996 "Software explosion rattles car makers"</h3>
<q>
Automakers [are facing] runaway growth in the lines of code their engineers
must write and manage as microprocessors take over automotive functions...
``Software is where the problem is today,'' said William Powers, VP of
research at Ford.  ``Today, if you change a line of code, you're looking at
the potential for some major problems.  Hardware is very predictable, very
repeatable.  Software is in much more of a transient state.''  The volume of
code is exploding as processors proliferate behind the dashboard and under
the hood.  The typical auto has 10 to 15 processors; high-end cars can have
as many as 80 ... ``An engine controller can have 100,000 lines of code''
[according to a Bosch VP].  
</q>
<br>
Posted to RISK digest 18.57 by Daniel P. B. Smith  dpbsmith@world.std.com
<hr>
<address>
<!WA1><a href="mailto:kornerup@tweety.cs.utexas.edu">Jacob Kornerup</a>
</address>
</html>

